The present invention relates generally to a method and apparatus for processing serial audio digital data, and more particularly, to a method and apparatus for interpreting and translating both audio and non-audio information contained within the serial data transmission.
The electronics industry currently offers a wide variety of digital audio devices, including compact disc players, digital audio tape players (DATs), digital sound samplers, digital signal mixers, various types of musical instruments, synthesizers, digital audio sound VCR players, etc. The digital audio data generated and/or received by these devices typically consists of a digital audio portion containing the audio data itself, and a number of auxiliary bits which define various attributes of the audio data, such as whether the data is copyrighted, or has undergone emphasis. The format and content of the auxiliary portion of the data often differs to varying degrees from one device to the next. This makes it difficult to directly communicate information between these different types of devices, and consequently reduces the versatility of these devices.
In attempt to solve this problem, various standards have been proposed for the formatting and transmission of serial digital audio, such as the EIAJ CP-340 standard, published in "Digital Audio Interface", CP-340, Electronic Industries Association of Japan, Sep. 1987, which is incorporated herein in its entirety by reference. As shown in FIG. 1, this standard defines a technique which transmits the serial audio data in units of frames. Each frame comprises two sub-frames, each comprising 32 bits of information. As shown in FIG. 2, the sub-frame itself includes a 4-bit preamble. Preambles are a specific pattern providing synchronization and identification of the sub-frames. For instance, a preamble "X" identifies that the subsequent serial data pertains to channel A, a preamble "Y" identifies that the subsequent serial data pertains to channel B, and a preamble "Z" identifies the start of a new block of data. A preamble "Z" occurs every 192 frames.
Bits 4-27 carry the audio sample data in linear 2's complement representation, with bit 27 serving as the most significant bit. The first four bits of this sample can be allocated for auxiliary data. Bit 28 comprises a validity flag. This flag is set to logical "0" when the audio data is reliable and set to logical "1" if unreliable, which, in turn, is determined on the basis of whether the previous audio sample bits were secure and error free. Bit 29 comprises a bit of user data, while bit 31 is a parity bit which reflects whether the information in the subframe has even or odd parity.
Bit 30 provides channel status information. The aggregate of channel status bits over an entire block (192 frames) can be conceptualized as a "channel status block" of information, consisting of twenty-four 8-bit bytes. The first entry in the block reflects whether the audio data is in a professional format or in a consumer format. FIG. 3 shows an exemplary channel status block for the consumer mode, where the consumer mode is indicated in the first bit of the block (PRO="0" for consumer mode).
The remainder of the first byte in the block shown in FIG. 3 includes an audio bit which identifies whether the data contained in the "audio" field is linear PCM audio information or data in some other format. The copy bit (bit 2) identifies whether the data is copyright inhibited or not. The pre-emphasis bits (bits 3-5) identify whether the audio data has been subject to preemphasis prior to transmission. The mode bits (bits 6 and 7) define subsequent bytes 1-3 of the block, and therefore govern the interpretation of these bytes.
In the second byte of information, bits 0-6 provide a category code, which identifies the type of equipment from which the serial audio data is being transmitted, while bit 7 provides information regarding whether the information is an original or a digital copy of a prerecorded work. The third byte includes bits 0-3 which identify a source number of the digital audio data and bits 4-7 which identify a channel number of the data. The fourth byte includes bits 0-3 which identify the sample frequency (44.1 kHz, 48 kHz, or 32 kHz), and bits 4 and 5 which identify the clock accuracy. The interested reader is referred to the above identified EIAJ text, incorporated here by reference, for a more detailed discussion of the myriad of coding permutations in the channel status block for different modes.
While the use of a standardized protocol (such as the EIAJ CP-340) promotes compatibility between different devices, the industry has not settled on a single protocol. Other well known serial digital audio standards include the IEC-958 standard, the EBU standard, the S/P-DIF standard, the I.sup.2 S (Philips) standard, and the AES standard. Many of these standards use the same general blocktype organization as the CP-340 standard discussed above. Nevertheless, there are differences in the choice and presentation of the channel status information which frustrate attempts to interface devices which employ these different standards. For example, formats may differ by excluding one or more channel status fields. For instance, the AES/EBU standard does not provide the "COPY" and "L" bit information contained in the EIAJ standard (shown in FIG. 3), although the audio data portion of the format is identical.
The prior art has attempted to accommodate this wide array of standards (and also different modes within standards, such as the consumer and professional modes) by designing interface circuits specifically tailored for different types of audio formatting. Other manufacturers have attempted to integrate separate circuits pertaining to different audio input protocols in one chip package. These devices typically require the system integrator to reconfigure the circuitry differently depending on the required input mode, such as by activating necessary circuit components and redefining the function and contents of various control and status registers. However, providing a separate circuit module for each protocol increases the complexity of the circuit. This results in systems which are relatively expensive. Also, the rapid pace at which the industry redefines and updates its standards limits the market lifetime of these devices.
The information coded in the channel status block is also a fairly low-level description of the data being transmitted. For this reason, when an application program attempts to interpret the audio data, it often must perform time consuming processing of the audio channel status information. In some standards, for instance, an application program must successively investigate various attributes and permutations of the status block bits in order to ascertain whether digital copying is permitted, such as by analyzing the category code, the copyright bit and the original/copy bit. In some instances, the software interface must determine the rate of change of various bits in the channel status block. This detracts from the efficiency of the application program, and imposes additional complexity on the software design (such as by requiring separate subroutines to process incoming audio data having different respective protocols).
For at least the above stated reasons, it would be desirable to provide a serial audio interface which allowed a device using one type of audio protocol to communicate with another device using a different type of audio protocol. Furthermore, it would be desirable to reduce some of the processing steps required by an application program in accessing and interpreting digital audio data.